1. Field of the Invention
The present invention relates to a method for manipulating a memory operation of a control unit program on a memory of a virtual or real electronic control unit (ECU), such as is used in motor vehicles, for example.
2. Description of the Background Art
Memory errors are not uncommon in control units, and can have fatal consequences depending on the safety level. The causes of memory errors are manifold:
EEPROM and flash memory for storing nonvolatile data have a limited number of write cycles. Usually, therefore, it is necessary to manage multiple redundant memory blocks with check sums. Writing to EEPROM or flash memory blocks takes a relatively long amount of time. Additional errors can arise during processing of a memory job that extends over multiple cycles.
Address lines and data lines from external memory components can be faulty.
Interference due to electromagnetic fields (EMC) or ionizing radiation can result in sporadic errors.
Temperature problems and general aging processes.
A simple examination shows that these problems cannot be neglected in safety-critical control units: If a control unit is installed in 1 million vehicles and has approximately 5,000 operating hours, then a task with a cycle time of 1 ms is executed a total of approximately 1.8*1016 times. During this time, it is guaranteed that almost every possible hardware and software error will occur.
Thus, precautions must be taken in the hardware and software design of control units to detect and intercept such memory errors. These precautions must be tested for release of a safety-critical control unit. However, such tests have proven to be very difficult and resource-intensive, since errors can only be induced with special hardware or elaborate hardware emulators.
The use of nonvolatile memory (NVRAM), in particular, has effects on the application software of an ECU as well. In similar fashion to bus errors, error conditions during reading and writing of the nonvolatile memory must be intercepted and handled. Another reason this is difficult is that read/write operations can extend over multiple cycles.
“Fault Injection Tests” are recommended in ISO standard 26262 at all levels, and indeed are required for the higher safety level (ASIL-D).
The approaches to testing of memory errors used heretofore for these purposes are based on hardware-specific prototypes or hardware emulators, which are very resource-intensive, and oftentimes have difficulty exactly reproducing error conditions that are generated.